Internet Tools (InfoMagic)/Internet Tools.iso/dos_win/winsock/hacklist/93-12.Z/93-12/[e-mail]_Tue Dec 14 12:45:34 1993.msg

Internet Message Format | 1993-12-30 | 20KB

Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
   From [e-mail] Tue Dec 14 01:12:44 1993
Received: from mica.inel.gov by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA10511; Tue, 14 Dec 1993 10:12:17 -0500
Received: from dewey.inel.gov (dewey.tis.inel.gov) by mica.inel.gov
    (4.1/INEL-MH-10.0) id AA01804; Tue, 14 Dec 93 08:11:51 MST
Received: by dewey.inel.gov (5.65/INEL-WKS-2.0)
    id AA06191; Tue, 14 Dec 1993 08:12:44 -0700
Date: Tue, 14 Dec 1993 08:12:44 -0700
From: [e-mail] (Dave Brooks)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: action on connection to full listening queue
In-Reply-To: <9312140645.AA24607@atlas>
References: <9312140645.AA24607@atlas>

[e-mail] writes:
 > I've been on BSD-patrol again trying to reconcile some small differences in
 > described bahaviour, and call for comments on this one:

Good deal, Paul.

 > The Windows Sockets spec states that when a connection attempt arrives for
 > a socket which is listening, and has filled its backlog, the connection
 > attempt will be returned, and the connecting socket will return
 > error WSAECONNREFUSED.
 >     The man-page for listen on our SunOS 4.1 box says the same thing.
 >
 >     The document "An Advanced Socket-Based Interprocess Communications
 > Tutorial" from Sun, however, states:

 > [ alternative behavior deleted]

 > My gut feel tells me the man-page and Windows Sockets description are
 > the appropriate way to go, although I can see merit in the alternative
 > behaviour.
 >
 >     The question is, which is the "correct" bahaviour, according to
 > Berkeley Sockets tradition?

There is merit in the alternative, but it's not "correct" according to the
WinSock spec or my understanding and experience with the BSD tradition.

OTOH, I've never seen a user respond positively to a "failure to connect".

Dave
From [e-mail] Tue Dec 14 06:10:00 1993
Received: from mineshaft.odi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA17457; Tue, 14 Dec 1993 11:10:14 -0500
Received: from odi.com (kayak.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5)
    id AA12556; Tue, 14 Dec 1993 11:10:01 -0500
Return-Path: <[e-mail]>
Received: by odi.com (4.1/SMI-4.0/ODI-15)
    id AA29535; Tue, 14 Dec 93 11:10:00 EST
Date: Tue, 14 Dec 93 11:10:00 EST
From: Ed Schwalenberg <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Dave Brooks's message of Tue, 14 Dec 1993 10:14:33 -0500 <[e-mail]>
Subject: action on connection to full listening queue

  Date: Tue, 14 Dec 1993 10:14:33 -0500
  From: [e-mail] (Dave Brooks)

   > The Windows Sockets spec states that when a connection attempt arrives for
   > a socket which is listening, and has filled its backlog, the connection
   > attempt will be returned, and the connecting socket will return
   > error WSAECONNREFUSED.
   >     The man-page for listen on our SunOS 4.1 box says the same thing.

  OTOH, I've never seen a user respond positively to a "failure to connect".

Indeed.  On the other hand, if an operating system kernel or a Windows Sockets
implementation were to use up infinite resources in an attempt to queue up
an infinite number of connections, the user at the listening end would probably
be just as unhappy as his peer who's attempting to connect.
That's why listen() has a backlog argument.

What I don't understand is why certain operating systems think that 5 is
an acceptable number for the maximum possible backlog.  Virtually every
customer we've ever had stress-tests our client-server database product by
starting up a zillion simultaneous clients; on the operating systems in
question some number of clients fail because our attempt to do listen(x, 100)
failed.
From [e-mail] Tue Dec 14 02:12:00 1993
Received: from netmail.microsoft.com ([131.107.1.13]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA15315; Tue, 14 Dec 1993 14:39:11 -0500
Received:  by netmail.microsoft.com (5.65/25-eef)
    id AA11351; Tue, 14 Dec 93 11:39:36 -0800
Message-Id: <9312141812.AA02663@itgmsm>
From: [e-mail]
To: [e-mail]
Subject: RE: action on connection to full listening queue
Date: Tue, 14 Dec 93 10:12:00 PST
X-Mailer: Microsoft Mail V3.0



|From: netmail![e-mail]
|
|The Windows Sockets spec states that when a connection attempt arrives for
|a socket which is listening, and has filled its backlog, the connection
|attempt will be returned, and the connecting socket will return
|error WSAECONNREFUSED.
|        The man-page for listen on our SunOS 4.1 box says the same thing.
|
|        The document "An Advanced Socket-Based Interprocess Communications
|Tutorial" from Sun, however, states:
|        "Should a connection be requested while the queue is full, the
|conection will not be refused, but rather the individual messages that
|comprise the request will be ignored. This gives the harried server time
|to make room in its pending connection queue while the client retries the
|connection request. Had the connection been returned with the ECONNREFUSED
|error, the client would be unable to tell if the server was up or not."
|
|My gut feel tells me the man-page and Windows Sockets description are
|the appropriate way to go, although I can see merit in the alternative
|behaviour.
|
|        The question is, which is the "correct" bahaviour, according to
|Berkeley Sockets tradition?

i see this as really a TCP question.  if a host receives a SYN for a
listening port which has reached the backlog limit, should the host respond
with a RST or should it ignore the SYN?  i scanned rfcs 793 and 1122 but
couldn't find an answer for this.  of the implementations i'm aware of, all
send the RST, but they also retry the SYN in response to a RST to smooth
over the case where the backlog is full, so the ECONNREFUSED as a result of
a full backlog is very rare--it would require that the backlog be full for
an extended period of time.

the disadvantage of ignoring the SYN is that the client does not know get
any acknowledgement that a path to the host exists.

[e-mail]
From [e-mail] Wed Dec 15 04:31:18 1993
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA05117; Tue, 14 Dec 1993 17:58:38 -0500
Received: by usage.csd.unsw.OZ.AU id AA16631
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 15 Dec 1993 09:20:53 +1100
Received: by atlas (4.1/1.35)
    id AA27288; Wed, 15 Dec 93 09:31:18 EST
Message-Id: <9312142231.AA27288@atlas>
From: [e-mail]
Date: Wed, 15 Dec 1993 09:31:18 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail], Multiple recipients of list <[e-mail]>
Subject: Re: action on connection to full listening queue

Thus expounded Ed Schwalenberg on Dec 14,11:12am:
/--------------------
|  Date: Tue, 14 Dec 1993 10:14:33 -0500
|  From: [e-mail] (Dave Brooks)
|
|   > The Windows Sockets spec states that when a connection attempt arrives for
|   > a socket which is listening, and has filled its backlog, the connection
|   > attempt will be returned, and the connecting socket will return
|   > error WSAECONNREFUSED.
|   >     The man-page for listen on our SunOS 4.1 box says the same thing.
|
|  OTOH, I've never seen a user respond positively to a "failure to connect".
|
|What I don't understand is why certain operating systems think that 5 is
|an acceptable number for the maximum possible backlog.  Virtually every
|customer we've ever had stress-tests our client-server database product by
|starting up a zillion simultaneous clients; on the operating systems in
|question some number of clients fail because our attempt to do listen(x, 100)
|failed.

Are you re-tranmsitting the SYN despite receiving one or two RST segments,
as the fine print in RFC1122 seems to indicate? (see my reply to David)
This would cause your client to wait a little longer, hopefully getting in when
your server has serviced a couple of the lucky early connections.


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Wed Dec 15 04:27:12 1993
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA05152; Tue, 14 Dec 1993 17:58:55 -0500
Received: by usage.csd.unsw.OZ.AU id AA16497
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 15 Dec 1993 09:16:45 +1100
Received: by atlas (4.1/1.35)
    id AA27282; Wed, 15 Dec 93 09:27:13 EST
Message-Id: <9312142227.AA27282@atlas>
From: [e-mail]
Date: Wed, 15 Dec 1993 09:27:12 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail],
        Multiple recipients of list <[e-mail]>
Subject: RE: action on connection to full listening queue

Thus expounded [e-mail] on Dec 14, 2:45pm:
/--------------------
||From: netmail![e-mail]
||
||The Windows Sockets spec states that when a connection attempt arrives for
||a socket which is listening, and has filled its backlog, the connection
||attempt will be returned, and the connecting socket will return
||error WSAECONNREFUSED.
||        The man-page for listen on our SunOS 4.1 box says the same thing.
||
||        The document "An Advanced Socket-Based Interprocess Communications
||Tutorial" from Sun, however, states:
||        "Should a connection be requested while the queue is full, the
||conection will not be refused, but rather the individual messages that
||comprise the request will be ignored. This gives the harried server time
||to make room in its pending connection queue while the client retries the
||connection request. Had the connection been returned with the ECONNREFUSED
||error, the client would be unable to tell if the server was up or not."
||
||My gut feel tells me the man-page and Windows Sockets description are
||the appropriate way to go, although I can see merit in the alternative
||behaviour.
||
||        The question is, which is the "correct" bahaviour, according to
||Berkeley Sockets tradition?
|
|i see this as really a TCP question.  if a host receives a SYN for a
|listening port which has reached the backlog limit, should the host respond
|with a RST or should it ignore the SYN?  i scanned rfcs 793 and 1122 but
|couldn't find an answer for this.  of the implementations i'm aware of, all
|send the RST

I take the view that a listening socket with a backlog of 'x' is just 'x'
sockets waiting for a connection. Since a listening socket automatically
replies and establishes the connection into the fully opened state, it is
no longer 'listening', so when the backlog is full there are no more
passive sockets waiting for a connection, so send a RST just as you
would if you had no listener on the port at all. This I guess is the logic
that causes all implementations to return RST.

, but they also retry the SYN in response to a RST to smooth
|over the case where the backlog is full, so the ECONNREFUSED as a result of
|a full backlog is very rare--it would require that the backlog be full for
|an extended period of time.

This is actually covered in RFC1122, page 101 I think:
    "An attempt to open a TCP connection could fail with excessive
retransmissions of the SYN segment or by receipt of a RST segment or an
ICMP Port Unreachable. SYN retransmissions MUST be handled in the general
way just described for data re-transmissions..."

    which to me basically means a connect() shold keep sending SYNs
even if it keeps getting RST segments back, at least for a reasonable
number of times. In fact, it would make sense to ignore return RSTs for
SYNs in this case, so the re-transmission logic automatically handles
backing off the retransmission interval for the SYN. Just record the fact
that a RST or ICMP Port Unreachable was encountered, so then the SYN
fails with excessive re-transmissions the error code ECONNREFUSED instead
of ETIMEDOUT is returned.

    This, of course, leads to exactly the same effect as ignoring
the incoming SYN if the backlog is full, in the hope that the backlog will
clear so that a re-transmitted SYN will be accepted, except for the
fact, as David notes below, that in this case you have no indication
of whether the SYNs reached the target or not when the attempt times out.

|the disadvantage of ignoring the SYN is that the client does not know get
|any acknowledgement that a path to the host exists.
|
|[e-mail]
\--------------------- {end}

    All these are really TCP implementation questions rather than
Sockets-related issues, and the guiding principle with Windows Sockets is
to "do unto others what BSD does unto you", so we'll go with the RST
and returning WSAECONNREFUSED as described in the spec. and listen() BSD man-
pages.


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Wed Dec 15 12:54:11 1993
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA10793; Wed, 15 Dec 1993 01:43:48 -0500
Received: by usage.csd.unsw.OZ.AU id AA04617
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 15 Dec 1993 17:43:35 +1100
Received: by atlas (4.1/1.35)
    id AA29101; Wed, 15 Dec 93 17:54:11 EST
Message-Id: <9312150654.AA29101@atlas>
From: [e-mail]
Date: Wed, 15 Dec 1993 17:54:11 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail]
Subject: multiple connect() attempts on a single socket

Question: If a connect() attempt fails for some reason after it has sent
network traffic (e.g. failure returns WSAETIMEDOUT or WSAECONNREFUSED),
is it necessary to support multiple subsequent connect() attempts, or
must the socket be closed then re-opened again.


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Wed Dec 22 21:48:52 1993
Received: from yarrina.connect.com.au by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA13341; Tue, 21 Dec 1993 19:01:12 -0500
Received: by yarrina.connect.com.au with UUCP id AA06157
  (5.67b8/IDA-1.5 for [e-mail]); Wed, 22 Dec 1993 11:01:04 +1100
Received: from dross.auspost.com.au (dross) by guk.auspost.com.au with SMTP id AA25283
  (5.65c/IDA-1.4.4); Wed, 22 Dec 1993 10:53:46 +1100
Received: by dross.auspost.com.au id AA26724
  (5.65c/IDA-1.4.4); Wed, 22 Dec 1993 10:48:52 +1100
Date: Wed, 22 Dec 1993 10:48:52 +1100
From: Dave Cole <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <9312212250.AA24350@atlas> ([e-mail])
Subject: Re: non-blocking connect() timeout after program exits

> How are you making the socket non-blocking - using ioctlsocket() or
> WSAAsyncSelect() - and if the latter, you could try calling
> WSAAsyncSelect with an argument lEvent=0L to cancel your interest
> in asynchronous events before closing the socket. You shouldn't
> have to do this, but it might get you going until the stack
> is fixed.

I never thought of making the socket non-blocking by using
WSAAsyncSelect()...  I wonder...

I will be a bit annoyed if the stack is able to cancel the connect if
I use WSAAsyncSelect() but not if I use ioctlsocket().

Thanks for your suggestion.

- Dave
From [e-mail] Wed Dec 22 04:50:06 1993
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA16999; Tue, 21 Dec 1993 19:59:52 -0500
Received: by usage.csd.unsw.OZ.AU id AA29715
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 22 Dec 1993 10:25:05 +1100
Received: by atlas (4.1/1.35)
    id AA24350; Wed, 22 Dec 93 09:50:06 EST
Date: Wed, 22 Dec 93 09:50:06 EST
From: [e-mail] (Paul Brooks)
Message-Id: <9312212250.AA24350@atlas>
To: [e-mail], [e-mail]
Subject: Re: non-blocking connect() timeout after program exits
Newsgroups: alt.winsock
In-Reply-To: <[e-mail]>
Organization: TurboSoft Pty Ltd, Sydney, Australia

In article <[e-mail]> you write:
|My setup: Windows 4 Workgroups TCP/IP
|
|My problem: I create a non-bocking socket, the fire off a connect to
|the unix based server.  if the server is not running on the unix box,
|the connect times out.  If I exit my program, before the timeout,
|going though all of the required shutdown; when the connect() times
|out, I am dumped back at the DOS prompt.
|
|Has anyone else seen this?

How are you making the socket non-blocking - using ioctlsocket() or
WSAAsyncSelect() - and if the latter, you could try calling
WSAAsyncSelect with an argument lEvent=0L to cancel your interest
in asynchronous events before closing the socket. You shouldn't
have to do this, but it might get you going until the stack
is fixed.

--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Thu Dec 30 13:36:18 1993
Received: from gordon-css583.army.mil ([192.108.177.3]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA02487; Thu, 30 Dec 1993 18:45:08 -0500
Message-Id: <[e-mail]>
Date:     Thu, 30 Dec 93 18:36:18 EST
From: MSG Junod John <[e-mail]>
To: [e-mail]
Subject:  connect timeout

Maybe this has been covered before, but how do you increase the timeout
on a "connect" call?  Is there a standard way in winsock to do this?

John
From [e-mail] Thu Dec 30 19:01:37 1993
Received: from mail.sni.de (news.sni.de) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA04076; Thu, 30 Dec 1993 19:01:37 -0500
Message-Id: <[e-mail]>
Received: from sni.de by mail.sni.de id <[e-mail]>;
          Fri, 31 Dec 1993 01:00:51 +0100
Subject: Cannot mail to harms.pad.
To: [e-mail]
Date: Fri, 31 Dec 93 1:01:19 MET
From: George Turnbull <[e-mail]>
X-Mailer: xmail 2.4 (based on ELM 2.2 PL16)


Cannot mail to harms.pad, empty mail.

-----------------  Unsent message follows:  -------------------------